達人プログラマー 第2版
https://gyazo.com/38a53917b6dbd2ec81cb388a6c2f1700
ちゃちい さんから誕生日のお祝いで達人プログラマー 第2版を頂きました..! ちゃちいさん、ありがとうございます!
今回から読書ノートのやり方を以下のように変える
code:Md
1.25分の時間を区切って読む
2.重要だと思った章をメモして、翌日復習の為の時間を5分取る
3.短期間での予習、復習を繰り返して、脳の記憶に定着させる
読書メモに関しては、重要な部分をメモする為にやっていることだが、それが頭に残らなければ意味がない。
間隔反復法に特化したWebサービスはないのかな..?
読書開始日:2020/12/5
達人の哲学
2020/12/5
復習: 2020/12/9
p1~p13
あなたの人生
この本はあなたの人生を扱っている
つまる所プラグラマー、またはエンジニアとして生きてく中で様々な課題が出てきた際に、アプローチの仕方や、解決手段、スタイル、哲学について取り扱っている。
達人プログラマーは眼の前の問題を考えるだけではなく、常にその問題より大きなコンテキストで捉え、常に物事の大局を見据えようとするのです。
p9割れ窓問題について
割れた問題(悪い設計、誤った意思決定、質の低いコード)をそのままにしてはいけません。発見と同時に修復してください。
なぜ割れた窓を見ると、人は放置してしまうのかというと、ネガティブな考えは伝染してしまうからです。
1つのネガティブな事が発生した場合それはチームにも伝染していきます。
逆に言えば、プロジェクトに割れ窓がなく、クリーンな状態であれば、窓を割れる人は現れにくいと考えられます。
p11石のスープと茹でガエル
戦争から帰ってきた兵士が村に帰ってきた。しかし、彼らは食料を恵んでもらえない。そこで彼らは湧いたお湯に石を入れ『あとは人参があれば美味しいスープができるのになぁ』とつぶやく。すると村人たちが興味を持ち、人参だけでなく様々な食材を持ち寄ってくれる。 最終的に兵士たちは石を取り除いて美味しいスープを食べました。めでたしめでたし。
これと同じような振る舞いはソフトウェア開発でも流用できる。システムの完成に必要なものがはっきりしている場合で、承認が必要となる場合、この例え話のように石(道理にかなった要求)をもちだし、関心を出して、動かせる..といった事を考えましょう。
一方でカエルのスープの例え話だと、カエルは徐々に変化が起きても気づきにくいため、スープに入れられてもそのまま茹で上がってしまう。これは割れ窓理論の話にも通じて、意思が悪い方向になっても気づきにくいのです。
あなたが、変化の触媒となる際に石のスープを作っているのか、それともカエルのスープを作っているのかを見極めてください。
2020/12/9
復習:2020/12/12
p14~
p17 あなたの知識ポートフォリオ:金融商品と同様に、エンジニアの技術やスキルもポートフォリオのように扱う
(1)定期的に投資する
技術的インプット、アウトプットを行う
具体例
毎年少なくとも1つの言語を学ぶ
月に1冊のペースで技術書を読む
技術書以外の書籍を読む
ソフトスキル = 対人スキル?
講習を受講する
近場のユーザグループに入る
これモチベーションの意味で大事
異なった環境に慣れ親しんでみる
最先端にとどまり続ける
(2)多様化する
1つのプログラミングの知識ではなく、MVCなどの設計、さらにそこから繋がるDIなどの概念
ネットワーク、DNS
MySQL
FW固有の知識
(3)リスクを管理する
技術の移り変わりは激しい。先を考えて変化が少なく伸びる技術をみてみる
(4)安価で買い、高値で売る
これは(3)と繋がる話で、無名の時にアーリアダプターとして学んでおくと、将来は多大な恩恵を受けることになる
(5)見直して再配分する
批判的な考え
見聞きしたものごとを批判的な目で分析する事
5つのなぜをとう
誰にメリットがあるのか
コンテキストはなにか?
誰にとって? 主語は?
それはいつ、どこで有効になるのか
これ大事で、それが導入された後の事を考えてみる
なぜこれが問題なのか?
問題になっている限界は何か?
p26 伝達しよう
聞き手がなにを知りたいのかを確認しよう
start:2020/12/12
復習:2020/12/21
第2章 達人のアプローチ
p34~p46
よい設計の本質について
良い設計は悪い設計よりも変更しやすい
ETCの原則
(Easy to Change) = 変更しやすくする
ETCはルールではなく価値
変更しやすいとそれだけで価値がある
将来の機能開発時に変更しやすい
テストも書きやすい
自分がコードを書いたことで変更しやすくなったかを意識してみる
DRYの原則について- 二重化の過ちについて
開発の問題は、開発の仕様書やプロセスは、プログラムの中で二重化してしまいやすいということです。
DRY(Don't Repeat Youserlf) = 繰り返しは避ける
二重化するの何が問題か?
DRY原則は「知識」や「意図」の二重化についての原則です。
コードの二重化
コメントの二重化も含まれる
コードにも同じ内容が書いていて、コメントにも同じ内容が書かれてる場合
どんなコメントをつけるべきかは自問自答してください
変数名や、関数名だけでも十分、意図が伝わるようにした方がいい。
再利用されやすいように実装を行う
クラス、関数
start:2020/12/21
p51~63`
p49 直交性
お互いが独自し交わっていない状態
それぞれのモジュールが独立している為、片方の変更がもう片方の変更に影響が与えにくい
例えば、PHPの中にHTMLが入っている例は直交性がないと言える
お互いが依存してしまっている為
直交性のメリット